The present invention relates generally to voice messaging systems, and more particularly to a multiple node messaging system wherein each Network Interface Unit or Telephony Services Platform (which is a form of Network Interface Unit) is shared by two or more host computers.
Messaging systems that provide voice, fax and/or e-mail messaging capabilities are well known. FIG. 1 illustrates an exemplary prior art messaging system developed by Unisys Corporation, Blue Bell, Pa., the assignee of the present invention. The system of FIG. 1 comprises multiple servers (which may be implemented, e.g., with A-series or Clearpath(trademark) computers offered by Unisys Corporation) each supporting a network applications platform (NAP), which provides an underlying platform for storage and retrieval of messages, and a messaging application running on the platform. A voice mail application, such as the Unisys Universal Voice Messaging System (UVMS), is an example of a messaging application that runs on the messaging platform. The UVMS application determines how calls to the messaging system are handled, what prompts are played to callers, and which features are available. Such applications typically maintain a database of subscribers who have xe2x80x9cmailboxesxe2x80x9d on the system. The messaging platform interfaces to a telephone network through a Network Interface Unit (NIU). Received messages are stored by the messaging platform in a local message store, or voice file.
The network applications platform, or NAP, may be located at a local telephone company connected to one or more central offices or switches, or could alternatively be located on the premises of a customer, such as a large or medium-sized company. In the latter case, the NAP would typically be connected to a private branch exchange (PBX) instead of directly to a PSTN. Telephone customers typically demand high (close to 100%) system availability, which means that, for a large customer having hundreds or even thousands of employees at a given location, it is extremely difficult to take the telephony application off-line for even a short time to make updates or modifications. Therefore, when it becomes necessary to modify the application in any way, the application provider needs a way to make such modifications in a way that maintains system availability. This need is particularly severe for high volume telephony systems, which typically cannot be taken out of service without inconveniencing significant numbers of users.
Network Interface Units are available from a number of different vendors. For example, NIUs suitable for use with the present invention include: (a) the Telephony Services Platform available from Unisys Corporation, Blue Bell, Pa.; (b) the Summa Four VCO 80 available from Summa Four, Inc., Manchester, N.H.; and (c) the Voice Frame 2020 available from Harris Corporation, Melbourne, Fla. The Telephony Services Platform (TSP) is most preferred. The difference between it and the other products just mentioned is that the TSP includes a board that plays back digitized voice from a voice file whereas the other products require a separate playback module.
In use, if a subscriber is not available when an incoming call is received, the Public Switched Telephone Network (PSTN) forwards the call to the messaging system, which typically allows the caller to record a message, and then will store the message for later retrieval by the subscriber. A key (or token) returned to the messaging application uniquely identifies the stored message data within the message store. This key can be used at a later time to retrieve the message from the message store for playback to the subscriber.
In the exemplary system shown in FIG. 1, a first node of the system comprises a server/NAP 10a, voice file and database 12a and NIU 14a. Similarly, a second node comprises a server/NAP 10b, voice file and database 12b and NIU 14b; and a third node comprises a server/NAP 10c, voice file and database 12c and NIU 14c. The first node, e.g., could be responsible for a predefined geographic area encompassing hundreds of thousands of subscribers, or simply for a predefined set of telephone lines or circuits. The respective nodes are separately coupled to a public switched telephone network, or PSTN, 16, and are thereby made accessible to their subscribers. Moreover, subscribers of one node can employ messaging to transfer copies of messages (such as voice messages) to subscribers of another node. The respective nodes may or may not share access to each other""s voice files (see copending application Ser. No. 09/161,214, filed Sep. 25, 1998, xe2x80x9cMultiple Node Messaging System Wherein Nodes Have Shared Access To Message Stores Of Other Nodesxe2x80x9d).
An important characteristic of a messaging system is that it be highly reliable and able to quickly recover from system failures. This characteristic is generally referred to as system xe2x80x9cavailability.xe2x80x9d The present invention relates to a messaging system architecture that comprises multiple redundant messaging nodes in order to achieve high availability. The present invention was developed in the process of designing a messaging system that would continue to provide access to user services even while one host computer (or disk) is inoperative or otherwise unable to process a call. A goal of the present invention is to implement the xe2x80x9cshared TSPxe2x80x9d concept described below such that each TSP has the ability to route a call to any one of a number of hosts. More particularly, the present invention was designed to permit a call routed to an application on one host to be transferred to an application on a different host.
Further background information concerning the construction and operation of messaging systems, and particularly systems employing a Network Applications Platform (NAP) for interfacing a telephone network and network applications running on an enterprise server, may be found in the following patents and copending patent applications, which are hereby incorporated by reference:
U.S. Pat. No. 5,133,004, Jul. 21, 1992, xe2x80x9cDigital Computer Platform for Supporting Telephone Network Applicationsxe2x80x9d;
U.S. Pat. No. 5,138,710, Aug. 11, 1992, xe2x80x9cApparatus and Method for Providing Recoverability in Mass Storage Data Base Systems Without Audit Trail Mechanismsxe2x80x9d;
U.S. Pat. No. 5,384,829, Jan. 24, 1995, xe2x80x9cDigital Computer Platform for Supporting Telephone Network Applicationsxe2x80x9d;
U.S. Pat. No. 5,323,450, Jun. 21, 1994, xe2x80x9cTelephone Network Applications Platform for Supporting Facsimile Applicationsxe2x80x9d;
U.S. Pat. No. 5,494,606, Feb. 20, 1996, xe2x80x9cMulti-Lingual Prompt Management System for a Network Applications Platformxe2x80x9d;
U.S. Pat. No. 5,633,916, May 27, 1997, xe2x80x9cUniversal Messaging Service Using Single Voice Grade Telephone Line Within a Client/Server Architecturexe2x80x9d;
U.S. patent application Ser. No. 08/944,924, filed Oct. 6, 1997, xe2x80x9cEnhanced Multi-Lingual Prompt Management in a Voice Messaging System With Support for Speech Recognitionxe2x80x9d (attorney docket TN078);
U.S. patent application Ser. No. 08/964,744, filed Nov. 5, 1997, xe2x80x9cMethods and Apparatus for Providing External Access to Executable Call Flows of a Network Applicationxe2x80x9d (attorney docket TN079);
U.S. patent application Ser. No. 08/987,571, filed Dec. 11, 1997, xe2x80x9cMultiple Language Electronic Mail Notification of Received Voice and/or Fax Messagesxe2x80x9d (attorney docket TN091);
U.S. patent application Ser. No. 09/094,126, filed Jun. 9, 1998, titled xe2x80x9cUniversal Messaging System Providing Integrated Voice, Data and Fax Messaging Services to PC/Web-based Clients, Including a Session Manager for Maintaining a Session Between a Messaging Platform and the Web-based Clientsxe2x80x9d (attorney docket TN094);
U.S. patent application Ser. No. 09/093,593, filed Jun. 9, 1998, titled xe2x80x9cUniversal Messaging System Providing Integrated Voice, Data and Fax Messaging Services to PC/Web-based Clients, Including a Content Manager for Receiving Information from Content Providers and Formatting the Same into Multimedia Containers for Distribution to Web-based Clientsxe2x80x9d (attorney docket TN095);
U.S. patent application Ser. No. 09/094,266, filed Jun. 9, 1998, titled xe2x80x9cUniversal Messaging System Providing Integrated Voice, Data and Fax Messaging Services to PC/Web-based Clients, Including a Large Object Server for Efficiently Distributing Voice/Fax Messages to Web-based Clientsxe2x80x9d (attorney docket TN096);
U.S. patent application Ser. No. 09/094,026, filed Jun. 9, 1998, xe2x80x9cSystem and Method for Integrating Notification Functions of Two Messaging Systems in a Universal Messaging Solutionxe2x80x9d (attorney docket TNN103); and
U.S. patent application Ser. No. 09/161,214, filed Sep. 25, 1998, xe2x80x9cMultiple Node Messaging System Wherein Nodes Have Shared Access To Message Stores Of Other Nodesxe2x80x9d (attorney docket TN102).
As discussed above, the present invention may be utilized to provide a xe2x80x9chigh availabilityxe2x80x9d messaging system comprising network interface devices (NIDs), such as TSPs or NIUs (the terms TSP and NIU are considered synonymous in the context of the present invention), that are shared by a number of host computers. The present invention is not limited to the specific interface device architectures disclosed herein, and so the term xe2x80x9cnetwork interface devicexe2x80x9d is intended to encompass NIUs in general as well as the TSP employed in the preferred embodiments. The xe2x80x9cInter-System Call Transferxe2x80x9d feature of the present invention permits a call routed to an application on one host to be transferred to an application on another host.
A telephony system in accordance with the present invention comprises a first host comprising a first telephony application, a second host comprising a second telephony application, and a network interface device (e.g., TSP or NIU) for routing calls on a plurality of telephone circuits to the first and second hosts, for processing by one of the first and second applications. (Typically, more than two hosts will be included in the system.) The network interface device includes the capability to transfer a call from one host to another host. Therefore, a call routed to a host that is unable to process the call can be redirected to another host that is able to process the call.
With respect to the present invention, the NID is a device that logically maps a plurality of telephone circuits to a plurality of host computers for processing by applications running on the host computers. In the presently preferred implementation of the invention, the NID is a TSP that comprises a plurality of Primary Rate Interface Modules (PRIMs), each of which includes a plurality of channels for receiving incoming calls. The inventive system is programmed to perform an Inter-System Call Transfer process. The basic Inter-System Call Transfer process comprises receiving a new incoming call via a selected one of the TSPs; assigning a TSP identifier to the incoming call; transferring the incoming call from the selected TSP to a bus; receiving the call in the first host; creating a call record in the first host; providing the call to the first application running on the first host; determining whether the first host can process the call; if the first host can process the call, passing the call to a first application running on the first host; and, if the first host cannot process the call, issuing a request to the selected TSP to transfer the call to the second host. In the preferred implementation, the TSPs each include a number of PRIMs, and each PRIM includes a plurality of channels for receiving incoming calls. The incoming call, therefore, may be assigned, in addition to a TSP identifier, a PRIM identifier and a channel identifier, for inclusion in the call record.
In the presently preferred implementation, a Transfer Port message containing information about the state of the call is created when a decision is made to transfer a call. The Transfer Port message preferably includes a call record containing information regarding the current host and application state, and information identifying the host to which the call is to be transferred. The Transfer Port message is transmitted from the first host to the TSP, and the TSP receives the message and routes it to the second host. The second host uses the call record information to recreate the state of the call on the second host, and then informs a second application running on the second host that the call is there.
The incoming call will typically include DTMF signals, which are received by the selected TSP, buffered in a local DTMF buffer, and then passed by the TSP to the first host. The DTMF signals are temporarily buffered by an Application Interface Module (AIM) in the first host, and then passed to the first application for processing. The AIM keeps a count of the number of DTMF digits that the first application has processed, as well as a timestamp for each signal. When a call transfer request is made by the first host, a purge DTMF operation is performed, whereby the selected TSP is caused to stop passing DTMF signals to the AIM and instead to buffer incoming DTMF signals in the local TSP buffer, thus allowing the selected TSP to determine which DTMF signals in its buffer have and have not already been processed by the first application. Any DTMF signals that have not yet been processed at the time the call is transferred are replayed to the second application on the second host, thereby preventing DTMF signals from being lost during the call transfer process.
Other features and aspects of the present invention are described below.